Prototyping the Semantics of a DSL using ASF+SDF: 
Link to Formal Verification of DSL Models 



Suzana Andova Mark van den Brand Luc Engelen 

Eindhoven University of Techinology 

P.O. Box 513, 5600 MB, Eindhoven, The Netherlands 

{S. Andova I M.G. J . v.d.Brand I L.J.P.Engelenj@tue.nl 



A formal definition of the semantics of a domain-specific language (DSL) is a key prerequisite for 
the verification of the correctness of models specified using such a DSL and of transformations ap- 
plied to these models. For this reason, we implemented a prototype of the semantics of a DSL 
for the specification of systems consisting of concurrent, communicating objects. Using this pro- 
totype, models specified in the DSL can be transformed to labeled transition systems (LTS). This 
approach of transforming models to LTSs allows us to apply existing tools for visualization and ver- 
ification to models with little or no further effort. The prototype is implemented using the ASFh-SDF 
Meta-Environment, an IDE for the algebraic specification language ASFh-SDF, which offers efficient 
execution of the transformation as well as the ability to read models and produce LTSs without any 
additional pre or post processing. 

1 Introduction 

Domain-specific languages (DSL) and model transformations are the key concepts in model driven engi- 
neering EOl . A DSL is a language that offers, through appropriate notations and abstractions, expressive 
power focused on, and usually restricted to, a particular problem domain |7|. A DSL enables domain 
experts to develop models using concepts in their own domain, rather than concepts provided by exist- 
ing formalisms, which typically do not provide the required or correct abstractions. DSL models can 
be further transformed into models in other languages using model transformations. Model transforma- 
tions can, for example, be used to transform DSL models into different implementations, each serving 
different purposes, such as validation, execution, testing, and visualization. 

In our previous work, we have designed the Simple Language of Communicating Objects (SLCO) Q, 
which provides constructs for specifying systems consisting of objects that operate in parallel and com- 
municate with each other. The structure of a system is modeled using classes and their behavior is 
modeled by state machines. Simultaneously to the development of the language, we implemented a 
number of model transformations to other languages as well as within the SLCO language. The goal of 
the previous work was to generate, for a given SLCO model, (i) its implementation in NQC for execution 
on the Lego Mindstorms platform |T|, (ii) its implementation in POOSL [21] for model simulation, and 
(iii) its implementation in Promela [ 14] for formal verification by means of the SPIN model checker [ 14 1. 
All three of these languages have semantic properties different from the semantics of SLCO, and there- 
fore, several semantic gaps needed to be bridged 13. These semantic gaps are bridged using model 
transformations, that transform SLCO models into SLCO models with equivalent observable behavior. 

The transformations from SLCO to NQC, POOSL, and Promela provide a partial transformational 
description of the semantics of SLCO, because each of these transformations only deals with a subset of 
SLCO. One of the goals of the work presented in this paper is to define the operational semantics of the 
entire language. 
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As for model transformations within SLCO, one way to reason about their correctness is to compare 
or relate the SLCO models before and after the transformation, by comparing or relating their imple- 
mentations. If, in addition, the implementation language is supported by a toolset allowing for model 
reduction, rather larger SLCO models can be handled, either for analysis or for model comparison. As 
Promela and SPIN do not provide support for these features, we have been motivated to look for an 
alternative solution, which would impose no restrictions on the SLCO expressiveness, too. 
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Itsconvert Tir^r^ " ^^ 
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CS -- LTS 



SLC02CS CS2LTS LTS2Dot 




Figure 1 : Overview of languages and tools 

In this paper we link the SLCO language to a simple language for the representation of labeled transi- 
tion systems, named simply LTS. Instead of selecting yet another target language supported by a toolset 
to which SLCO models will be transformed, we decided, first, to transform SLCO into LTS and, then, to 
link LTS to existing languages and toolsets (see Figure [TJ. The reason is that LTS, due to its simplicity, is 
much easier to link to other languages: languages that we have selected as appropriate for our purposes, 
such as those described in Section |4] but also other languages which may show useful in the future. In 
our case, we achieve this by a rather easy transformation from LTS to Dot, a language for the graphical 
representation of graphs that is also used by third-party tools to represent LTSs. Thus, our main effort is 
on translating SLCO to LTS. Once the translation into LTS has been achieved, different tools supporting 
LTSs are also within reach for manipulation, visualization, and verification of SLCO models. Our lan- 
guage transformations are defined and implemented in the ASF-i-SDF Meta-Environment [6J. We find its 
ability to generate command-line tools that can efficiently execute transformations as well as its ability to 
parse arbitrary context-free languages very beneficial and advantageous for our approach. As shown in 
Figure [T| our SLCO environment at the back-end can be connected to various already developed toolsets 
for various purposes. 

Yet another motivation to take this approach is the following: the implementation of the transforma- 
tions from SLCO models to LTSs gives a prototype of the semantics of SLCO. As shown in Figure[T] there 
is an intermediate representation language used, called CS, and therefore, two main transformation steps: 
SLC02CS and CS2LTS. While objects in an SLCO model are defined separately and communicate via 
channels, in the CS representation of the same system the objects are merged into one (big) component, 
according to the communication as defined in the SLCO model. Thus, CS links, in a rather natural way, 
the two languages SLCO and LTS. The transformation from SLCO to CS essentially forms the core of the 
prototype semantics of SLCO, as the transformation from CS to LTS is rather straightforward. The imple- 
mentation of this transformation has helped to gain a better understanding of the effect of various design 
decisions on the semantics of SLCO, in a larger part by the verboseness of the intermediate language 
CS and the visual representation of LTSs produced by external tools. Based on the conditional rewrite 
rules which form the core of this transformation, the formal operational semantics of the language can 
be defined, but this goes beyond the scope of this paper. While our environment is built around SLCO, we 
beUeve that the same methodology can be applied to other DSLs. 

Structure of the paper In Section [2j SLCO is briefly described. In Section |3j the main ingredients of 
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the transformation environment, the languages and the tools, are introduced, and in Section [4| we link 
this environment to existing languages and tools. Section [5] addresses the related work, and Section [6] 
concludes the paper and discusses future work. 

2 The Simple Language of Communicating Objects - SLCO 

The Simple Language of Communicating Objects (SLCO) provides constructs for specifying systems 
consisting of objects that operate in parallel and communicate with each other. Figure |2] shows the 
main metaclasses and relations of the SLCO metamodel. The remainder of the metamodel is shown in 
Figure[3| which shows the subclasses of the abstract metaclasses Statement, Trigger, and Expression, and 
the related metaclasses and relations. 
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Figure 2: Overview of the SLCO metamodel 



An SLCO model consists of a number of classes, objects, and channels. Objects are instances of 
classes and communicate with each other via channels, which are either bidirectional of unidirectional. 
SLCO offers three types of channels: synchronous channels, asynchronous lossy channels, and asyn- 
chronous lossless channels. An example of two objects connected by three channels is shown in Figure|4] 
The objects p and q, which are instances of classes P and Q, can communicate over channels pl-ql, 
q24>2, and p3.q3. The arrows at the ends of the channels denote the direction of communication. Syn- 
chronous channels are denoted by plain lines (e.g. pl^l), asynchronous lossless channels are denoted 
by dashed lines (e.g. p3.q3), and asynchronous lossy channels are denoted by dotted lines (e.g. g2_p2). 
A channel can only be used to send and receive signals with a certain signature, indicated by a number 
of argument types augmented to the channel. Channel /7l_^l, for instance, can only be used to send and 
receive signals with a boolean argument, and channel ^2_p2 only allows signals without any arguments. 

A class describes the structure and behavior of its instances. A class has ports and variables that 
define the structure of its instances, and state machines that describe their behavior. It is possible to 
specify the initial values of variables. If no initial value is specified, integer variables are initialized to 0, 
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(b) Expressions 
Figure 3: Statements, triggers, and expressions in SLCO 



boolean variables are initialized to true, and string variables are initialized to the empty string. Ports are 
used to connect channels to objects. Figure |4] shows that object/? has ports PI, P2, and P3, connecting 
it to channels /7l_^l, q2^2, and;73_^3, and that object q has ports Ql, Q2, and Q3, connecting it to the 
same channels. 

A state machine consists of variables, states, and transitions. SLCO allows for two special types of 
states: a state can be an initial state or a final state. Each state machine has exactly one initial state, 
and can contain any number of ordinary and final states. Figure [5] shows an example of an SLCO model 
consisting of two state machines, whose initial states. Initial, are indicated by a black dot-and-arrow, 
and whose final states are denoted as circled black dots. As explained below, the left state machine 
specifies the behavior of object p and the right state machine specifies the behavior of object q, both 
already introduced in Figure |4] 

A transition has a source and a target state, and possibly a guard, a trigger, a number of statements 
that form its effect, or a combination of these. A guard is a boolean expression that must hold to enable 
the transition from the source to the target state to be taken. For instance, [n >= 2] is the guard of the 
transition with the source State and the final state as the target state in the state machine oi p. There 
are two types of triggers: a signal reception and a delay. A transition with a delay trigger is enabled 
after a specified amount of time has passed since entering its source state. Note that our running example 
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Figure 4: Objects, ports and channels in SLCO 
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Figure 5: Two SLCO state machines 



does not have this type of triggers. A transition with a signal reception trigger is enabled if a signal is 
received via the port indicated by the trigger. When a signal reception trigger is combined with a guard, 
naturally, the guard must hold for the transition to be enabled. It is allowed for the guard to refer to 
arguments of the signal just being received, which yields a form of conditional message reception. Take 
for instance the transition in q from State to the final state, with trigger receive Stop(m) from Q3. It 
is only taken if the value of the argument sent with the signal Stop is smaller than 2, specified as [wi<2]. 
Additionally, another form of conditional signal reception is offered. Expressions given as arguments 
of a signal reception specify that only signals whose argument values are equal to the corresponding 
expressions are accepted. Thus, q in state Initial accepts only signals whose argument equals true. 

When a transition is made from one state to another state, the statements that constitute the effect 
of the transition are executed. SLCO offers statements for assigning values to variables and for sending 
signals over channels. The state machines in Figure |4] specify the following communication between/? 
and q. The two objects first communicate synchronously over channel /7l_^l, after which q repeatedly 
sends signals to p over the lossy channel q2_p2. As soon as p receives 2 of the signals sent by q, it sends 
a signal over channel p3.q3 and terminates. After receiving this signal, q terminates as well. 

In addition to the graphical concrete syntax shown above, SLCO has a textual concrete syntax, which 
is used by the tools described in Section [3] to perform transformations of SLCO models. Listing [T] shows 
a part of the textual equivalent of the model described above. 

3 Prototyping Semantics 

Figure [T] shows that the SLCO transformation environment involves other languages and transformation 
tools. Designing the environment and defining its main ingredients required, among others, thorough 
understanding of the SLCO semantics, and its specification in terms of basic activities, each one either 
being executed by a particular object or being the result of objects' interaction. The idea behind the 
intermediate language CS is to specify explicitly these low-level activities, which are implicit in SLCO, 
and to serve as an underlying language to express the semantics of SLCO. As a result, CS together with the 
SLC02CS transformation captures the semantics of SLCO. All languages and transformations described 
in this section are available for download |[T6]| . 



3.1 Languages 

The process of transforming an SLCO model into an LTS is split into two steps. First, the SLCO model 
is translated into a list of configurations and steps, represented in the CS language, where CS stands for 
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model M { 
classes 
P { 

variables Integer n 
ports PI P2 P3 
state machines 
P { 

initial Initial state State final Final 
transitions 

Receive from State to State { 
trigger receive V() from P2 
guard n <= 1 
effect n := n + 1 } 

} 
} 

obj ects p : P q : Q 

channels pl_ql (Boolean) sync from p. PI to q.Ql 



Listing 1 : Part of a textual SLCO model 



Configurations and Steps. In this language, we describe the behavior of the entire system, resulting from 
the communication of the constituting objects, which are originally modeled as a set of separate state 
machines in SLCO. Then, this CS representation is transformed into a list of states and transitions, which 
form the LTS representation of the input model. 

< 

<p, P, Inltlal> <q, Q, Inltlal>, 
[<<p, n>,0>, <<q, m>,0>], 

[<<p3_q3 , p, P3 , q, q3>,>, <<q2_p2, q, Q2 , p, P2>,>], 
initial 
> 

Listing 2: The initial configuration of the running example 

CS The main ingredients in a CS description are configurations and steps. A configuration is a repre- 
sentation of a possible state of the system described by the SLCO model. A configuration can make a step, 
after which the system reaches another configuration. It is important to note that a step in CS does not 
correspond to a ti^ansition in SLCO, but, in general, several steps (not necessarily executed in sequence) 
accomplish the behavior specified with such an SLCO transition. Therefore, the CS representation of an 
SLCO model refines its behavior by splitting the execution in more basic activities. 

Each configuration consists of three mandatory parts and an optional status. The configuration given 
in Listing |2] is the initial configuration of the model consisting of objects p and q, shown in Figures |4] 
and|5] The first part of a configuration specifies the current states of all state machines of all objects in the 
SLCO model. This part of the configuration is referred to as the active states of a configuration. If a state 
machine sm of an object o is currently in state st, this is specified as <o , sm , st> in the active states part 
of the configuration. This type of active state is referred to as plain active state. Recall now that the effect 
of an SLCO transition may consist of several statements. Thus, in general, the state machine can start 
executing the transition by receiving a signal, for instance, after which it starts executing the statements 
forming the effect of this transition. All these parts of the transition's execution are represented as 
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separate steps in a CS model. In view of the whole system, this means that the state machine to which this 
transition belongs to cannot proceed with any other transition as long as all statements are not executed; 
however, any other state machine is allowed to proceed with its own execution. In order to specify 
these intermediate configurations in the CS model, we introduce a second type of, so-called, partial 
active states. A partial active state <o, sm, st, k, ni> represents that the kth statement in the list 
of statements is to be executed next as a part of the execution of the mth outgoing transition of state st. 
Consequently, the active states part of a configuration consists of a number of plain and partial active 
states, as many as the state machines in the model. 

In the configuration shown in Listing |2] both active states, viz. <p, P, Initial> and <q, Q, 
Initial>, are plain. Listing |3] gives an example of a configuration in which <q, Q, State> is a 
plain active state and <p , P , State , , 1> is a partial active state, the latter indicating that the state 
machine oip (Figure[5]) has to execute the 0th statement, n : =n+l, in the list of statements of the outgoing 
transition of state State whose identifier equals 1. 

< 

<p, P, State, 0, 1> <q, Q, State>, 
[<<p, n>,0>, <<q, m>,0>], 

[<<p3_q3 , p, P3 , q, QS > , > , <<q2_p2 , q, Q2 , p, P2>,>] 
> 

Listing 3: A configuration containing a plain active state and a partial active state 

The second part of the configuration, the valuation part, maps variables to values. In the example 
configuration in Listing |2j it is specified as [<<p,n>,0>, «q,m>,0>] , expressing that variable n of 
object p and variable m of object q both have value in this configuration. 

The third part of the configuration represents a set of buffers and is simply referred to as the buffers 
of the configuration. For each asynchronous channel in the model, one or two buffers are introduced: in 
case of a bidirectional channel two buffers are introduced and in case of a unidirectional channel one 
buffer is introduced. The configuration in Listing [2] contains two buffers, one for each (unidirectional) 
channel, and they are both empty. The first buffer corresponds to channel p^jq'i and the second buffer 
corresponds to channel q2_p2. Because channel p\-q\ is synchronous, it has no corresponding buffer. 
The optional status of this configuration is set to initial. If all state machines in a configuration are in a 
final state, the status of this configuration is set to final. 

The dynamics of the system modeled by a set of communicating objects is represented by steps. Each 
step has a source and a target configuration, and an optional label. A step is a representation of a (basic) 
activity a given state machine has to perform as a part of the set of activities assigned to a transition 
in the SLCO representation of this state machine. Listing |4] shows two steps from the CS model of our 
SLCO running example model. The first step has a label that represents the reception of the asynchronous 
signal V by the state machine of p. The second step represents the execution of the assignment statement 
n : = n + 1 of this state machine and does not have a label. 

LTS The language LTS is a simple language for representing labeled transition systems as a list of 
states and a list of transitions. A state can be typed as initial or final state. Each transition is described 
as a couple of states, the source and the target states, and an optional label. Listing |5] shows the LTS 
description of a tiny LTS with four states and three transitions. State is declared as an initial state, 
and states I and 3 are final states. There are three transitions, one of which has label a. There are 
different languages that describe LTSs; the ones used in our environment are described in Section[4] The 
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< 

< 

<p , P, State> <q, Q, State>, [<<p, ii>,0>, <<q, m>,0>], 
[<<p3_q3 , p, P3 , q, Q3>,>, <<q2_p2 , q, q2 , p, P2>,<V, >>] 

> , 

" receiving V () " , 
< 
<p, P, State, 0, 1> <q, Q, State>, [<<p, n>,0>, <<q, m>,0>], 
[<<p3_q3 , p, P3 , q, Q3>,>, <<q2_p2 , q, q2 , p, P2>,>] 
> 
> 
< 
< 
<p , P, State, 0, 1> <q, Q, State>, [<<p, ii>,0>, <<q, m>,0>], 
[<<p3_q3 , p, P3 , q, Q3 > , > , <<q2_p2 , q, Q2 , p, P2>,>] 

> , 
< 

<p , P, State> <q, Q, State>, [<<p, ii>,l>, <<q, m>,0>], 
[<<p3_q3 , p, P3 , q, Q3 >,>,<< q2_p2 , q, Q2 , p, P2>,>] 



Listing 4: Two steps depicting the reception of a signal and the execution of an assignment statement 



most notable feature of LTS in comparison to these other languages is that it has a notion of final state, 
to distinguish between successful termination and deadlock. A state without any outgoing transitions 
represents a deadlock. It is considered undesirable for a system to reach these deadlock states. Reaching 
a final state and thus terminating successfully, however, is considered desirable behavior. 

states 

initial 

final 1 

2 

final 3 
transitions 

1 

"a" 2 

2 3 



Listing 5: An example of an LTS 



3.2 Tools 

Now that the languages used to prototype SLCO are in place, we describe the two main transformations 
of our environment in this subsection. The first transformation produces a CS representation of an input 
SLCO model and the second transformation produces an LTS from the CS representation (Figure [T]). As 
these transformations are implemented in the ASF+SDF Meta-Environment IS, we briefly describe it 
here as well. 

ASF+SDF The language ASF+SDF is a combination of the two formalisms ASF Pl and SDF GS. 
SDF stands for Syntax Definition Formalism. It is a formalism for defining syntax of context-free lan- 
guages. ASF stands for Algebraic Specification Formalism. It is a formalism for the definition of condi- 
tional rewrite rules. Given a syntax definition in SDF of the source and target language, ASF can be used 
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to define a transformation from tlie source language to tiie target language. In ASF, conditional rewrite 
rules are specified using the concrete syntax of the input and output languages. 

ASF in combination with SDF guarantees syntax safety of the implementation of the transformations. 
A transformation is syntax safe if it only accepts input that adheres to the syntax definition of the input 
language, and it always produces output that adheres to the syntax of the output language. 

The ASF+SDF Meta-Environment is an IDE for ASF+SDF It has a graphical user interface that 
offers syntax-highlighting for the specification of SDF and ASF definitions, and an interpreter and de- 
bugger for the execution and debugging of ASF specifications. The Meta-Environment can be used to 
create a command-line tool that parses and rewrites input adhering to the syntax definition of the input 
language, and outputs the result. These command-line tools employ memoization, which ensures that 
the result of a rewrite rule applied to a given term is computed only once. Both the ASF-i-SDF Meta- 
Environment and the command-line tools it generates use Annotated Terms (ATerms) [5 1 to represent 
terms internally. Because ATerms offer maximal subterm sharing, the internal representation of terms 
uses as little space as possible. 

SLC02CS An SLCO model is translated into CS in three phases. First, the initial configuration of the 
SLCO model is constructed. The list of active states of this initial configuration consists of the initial 
states of each of the state machines of the objects in the model, the valuation maps all variables to their 
initial values, and the buffers corresponding to all asynchronous channels are empty. Second, the set of 
all reachable configurations is generated. This phase is described in more detail below. Third, the list of 
configurations is traversed to find the configurations containing only active states that are final, and these 
configurations are marked as final. 

In the second phase, first all configurations that are reachable from the initial configuration are cre- 
ated, as well as all the steps from the initial configuration to the reachable configurations. Then, all 
configurations that are reachable from these new configurations and the corresponding steps are created, 
and so on, until no new configuration is found. The configurations that are reachable from a source 
configuration are computed based on the active states of this source configuration. A step from one con- 
figuration to another is possible if one of the active states of the source configuration has an outgoing 
transition that is enabled or can execute a statement, in the corresponding SLCO state machine. Whether 
a transition is enabled depends on the valuation of the variables and the contents of the buffers of the 
source configuration. The valuation of the variables is used to determine whether the optional guard of 
such a transition holds and the content of the buffers is used to determine whether any signal receptions 
are possible. To determine all the configurations that are reachable from a given source configuration, all 
outgoing transitions of all active states of the source configuration are considered. The SDF functions 
discussed next are selected from the set of all functions that all together implement the generation of 
configurations and steps within the second phase of the transformation. 

Listing [6] shows the signature of the functions takeStepTransition and takeStepPartialTransition. Ap- 
plying these functions to terms representing a model, a configuration, an active step, and a transition 
results in a term representing a list of configurations and a list of steps. The function takeStepTransition 
is meant for handling plain active states, whereas the function takeStepPartialTransition is meant for 
handling partial active states. 

Listing [7] shows one of the conditional rewrite rules in ASF that implement the function takeStep- 
Transition. In the rules in Listing [7j [8} and|9j all variable names start with a dollar sign. In ASF-i-SDF, 
each term conforms to a sort and variables represent arbitrary terms of some sort. Variable names that 
end with a plus symbol represent lists of more than one terms of a sort and variable names that end with 
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takeStepTransition( 

Model, Configuration, ActiveState, Transition 
) -> <Conf igurat ion* , Step*> 

takeStepPartialTransition( 

Model, Configuration, ActiveState, Transition 
) -> <Conf igurat ion* , Step*> 

Listing 6: SDF definition of the functions that compute all possible steps from configurations 



a question mark represent zero or one term. For example, the variables $Statenient+ and $Guard? in 
Listing [Tjrepresent one or more statements and an optional guard, respectively. The first part of an ASF 
rule consists of the conditions of that rule. After an arrow (====>), the left-hand side and right-hand 
side of the rule follow, separated by an equal sign. If all the conditions hold, the left-hand side can be 
replaced by the right-hand side. The rules described in this paper use only one kind of condition: a 
matching condition. A matching condition consists of a right-hand side and a left-hand side, separated 
by a colon and an equal sign. The condition holds if both sides can be matched. In this case, the variables 
occurring at the right-hand side are instantiated such that both sides match. 

The rule in Listing [7] deals with transitions with a signal reception trigger and an effect consisting 
of more than one statement. The source state of such a transition is represented by a plain active state. 
Because the effect of the transition consists of several statements, the plain active state provided as input 
is replaced by a partial active state in the resulting configuration. This partial active state indicates that 
none of the statements that form the effect have been executed yet and that the transition that has been 
taken from state $ActiveState has identifier $NatCon. The first step in Listing [4] is produced by applying 
this rule. 

[t akeStepTr an sit ion -reception -1] 

<$IdConO , $IdConl , $IdCon2> := $Act i veSt at e , 
$IdCon3 from $IdCon2 to $IdCon4 { 

trigger $SignalRecept ion 

$Guard? 

effect $Statement+ 
} := $Transition , 

$NatCon := getTransit ionNumber ( $Model , $Transition, $Act i veState ) , 
$ActiveStateO := <$IdConO , $IdConl , $IdCon2 , 0, $NatCon>, 
<$Conf igurat ionO , $StepO> := pr ocessSignalRecept ion ( 

$SignalRecept ion , $ActiveState , $Act iveStateO , $Model , $Conf igurat ion , 

$IdConO , $IdConl 
) 

takeStepTransitionC 

$Model , $Conf igurat ion , $ Act iveSt at e , $Transition 
) = <$Conf igurationO , $StepO> 

Listing 7: ASF rule that specifies how a signal reception trigger on a transition from a plain active state 
is processed 



Listing [8] shows yet another of the conditional rewrite rules that implements the function takeStep- 
Transition. This rule applies to transitions that have no trigger and only one single assignment statement 
that forms its effect. In the configuration resulting from this rule, the original active state is replaced 
by another plain active state, because the effect consists of only one statement. The function processAs- 
signmentStatement, used by the function takeStepTransition, produces a configuration and a step. The 
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configuration is an updated version of tfie configuration provided as input, in whicii the active state $Ac- 
tiveState is replaced by $ActiveStateO and the valuation is adapted according to the assignment statement. 
The step consists of the original configuration and the updated configuration. 

[takeStepTransition -assignment -0] 

<$IdConO , $IdConl , $IdCon2> := $Act i veSt at e , 
$IdCon3 from $IdCon2 to $IdCon4 { 
$Guard? 

effect $AssignmentStatement 
} := $Transition, 

$ActiveStateO := <$IdConO , $IdConl , $IdCon4>, 
<$Conf igurat ionO , $StepO> := process Ass ignment St atement ( 

$AssignmentStatement , $Act iveStat e , $ActiveStateO , $Conf iguration , 
$IdConO , $IdConl 
) 

takeStepTransition ( 

$Model , $Conf igurat ion , $ActiveState , $Transition 
) = <$Conf igurationO , $StepO> 

Listing 8: ASF rule that specifies how a single assignment statement on a transition from a plain active 
state is processed 



Listing |9] deals with transitions with an optional guard, an optional trigger, and an effect consisting 
of more than one statement. The source state of this transition is a partial active state. The function 
getStatements that is used by this rule takes a list of statements and an transition identifier and returns the 
statement with the given index and all following statements. One of the matching conditions states that 
this rule only applies if the statement with index $NatConO is an assignment statement and that there are 
no statements after this statement. The second step of Listing |4] is the result of applying this rule to the 
target configuration of the first step. 

[takeStepsPartialTransition-assign-O] 
$IdCon3 from $IdCon2 to $IdCon4 { 

$Trigger? 

$Guard? 

effect $Statement+ 
} := $Transition , 

$AssignmentStatenient := get St at ement s ( $Stat ement + , $NatConO), 
$ActiveStateO := <$IdConO , $IdConl , $IdCon4>, 
<$Conf igurat ionO , $StepO> := process Ass ignment St at ement ( 

$AssignmentStatement , <$IdConO, $IdConl , $IdCon2, $NatConO , $NatConl>, 

$ActiveStateO , $Conf iguration , $IdConO , $IdConl 
) 

takeStepPartialTransitionC 

$Model , $Conf iguration , <$IdConO, $IdConl , $IdCon2, $NatConO , $NatConl > , $Transition 
) = <$Conf igurationO , $StepO> 

Listing 9: ASF rule that specifies how an assignment statement on a transition from a partial active state 
is processed 



CS2LTS The tool CS2LTS translates lists of configurations and steps from CS to LTS, as shown in Fig- 
ure [T] and it is also implemented using ASF+SDF The way we have defined CS makes this translation 
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rather straightforward. Each configuration is mapped to a unique natural number and, possibly, an op- 
tional status. The optional status indicates whether a state in the LTS is an initial or a final state and it is 
equal to the status of the configuration that corresponds to the state. Each step is transformed to a pair of 
natural numbers representing its configurations, possibly decorated by an optional label. The label of a 
transition is equal to the label of the corresponding step. 



4 Verification and Visualization 



4.1 Visualization 



Start(true) 




lost V() 



V() 
igStop(l) 



receiving V() 







receiving V() 



Figure 6: An LTS visualized using Dot 



O 



Figure 7: A reduced LTS visualized using Dot 



The Dot language is a language for graph visualization that is part of the graph viz toolset |[TOll . 
We use this language to visualize LTSs, by translating LTSs to graphs in the format of the Dot language. 
This translation is straightforward, because the way graphs are described in this language is similar to the 
description of LTSs. A graph description in Dot is a list of nodes and edges from node to node, combined 
with attributes that specify how particular nodes and edges should be displayed. These attributes define, 
for example, the color, width, height, and the type of line used to draw these nodes and edges. LTSs are 
transformed to Dot graphs by translating all states to nodes and all transitions to edges, and specifying 
how initial states, final states, and normal states should be visualized. Figure |6] shows the LTS that 
corresponds to the model in Figure[4]and[5j visualized using Dot. In the visual representation, a transition 
label is always place on the right-hand side of the transition. Several transitions do not have labels, as 
they correspond to assignment statements. 
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4.2 Verification 

For small LTSs, like the one in Figure [6} it is easy to verify properties manually by inspecting the graph. 
In case of larger LTSs, reduction techniques can be applied to first reduce the LTS before verifying 
properties manually. The tool Itsconvert, which is part of the mCRL2 toolset [13], takes an LTS in various 
formats as input and converts it to an equivalent LTS in another format. One of the formats that Itsconvert 
is able to process is the Dot format, which although meant to describe graphical representations of graphs, 
is also used to represent LTSs. The tool is also capable of reducing LTSs, by means of an equivalence 
relation, and several equivalence relations are supported. Figure|7]shows the LTS obtained after reduction 
has been applied to the LTS in Figure [6} by means of the branching bisimilarity relation [12| . The LTS 
has been reduced by, first, turning all labels except receiving V() to internal unobservable labels and 
then removing all redundant states and transitions using Itsconvert. A similar procedure can be applied 
for other reductions this tool supports. After the reduction, it is obvious that the following property holds 
in our running example: "signal V is received exactly two times." 

As mentioned in Section [TJ there exists a number of transformations that transform SLCO models 
into other SLCO models with equivalent observable behavior. By producing an LTS for the input and the 
output model of such a transformation, and reducing both LTSs using the technique described above, the 
correctness of this transformation for the given input model can be verified by comparing the reduced 
LTSs. If reducing the LTS of both models leads to the same LTS, the transformation has indeed preserved 
the observable behavior. 

When LTSs get too large for reduction and manual inspection, other tools can be used for verification. 
One approach is converting LTSs to the BCG and AUT file formats that are used by the CADP toolset 111] 
to represent LTSs. The CADP toolset offers tools that take an LTS and a temporal logic property as input 
and perform on-the-fiy verification of the property on the LTS. Alternatively, the previously mentioned 
mCRL2 toolset can be used for verification too. This toolset includes a tool that can transform LTSs to 
the proprietary format of the toolset, and tools that can be used to analyze, simulate, manipulate, and 
visualize models described using this format. These two example toolsets clearly show the added benefit 
of producing LTSs from SLCO models. Transforming models to this common description format makes 
it possible to verify properties of models using existing tools, without additional effort. 

5 Related Work 

Hooman and Van der Zwaag |[T5l used the interactive theorem prover PVS to define the semantics of a 
subset of the UML. In this subset, the behavior of objects is specified using state machines that com- 
municate with each other both synchronously and asynchronously. Proving properties of models in this 
approach is done manually using PVS. This is a complex task that requires expertise in PVS, which can 
be simplified using certain predefined strategies. A disadvantage of this approach is that is does not offer 
the reusability of other existing tools that our approach offers. An advantage of this approach is that it 
does not suffer from the state-space explosion problem, because the complete state space of models does 
not have to be generated for property verification. 

Di Ruscio O et al. define the semantics of a DSL for the development of telephony services using 
Abstract State Machines (ASM). Because ASMs can be executed, this definition can be used to simulate 
models specified in their DSL. The approach is meant for the specification of the behavioral semantics 
of the DSL only, and does not offer verification of models. Proving properties for all models in general 
or any specific model is not investigated. In theory, however, properties of models could be verified in 
the domain of ASMs. 
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Sadilek and Wachsmuth |[T9]| propose a technique for defining the semantics of DSLs that uses model 
instances as configurations and QVT relations to define steps between configurations. Configurations, 
representing model instances, can be visualized using the same editors used to create models. By reusing 
the existing editors, visual interpreters and visual debuggers can be created with relatively little effort. 
Although this technique is suited for simulation of models, it is not efficient enough for state-space 
generation. Because each configuration is represented by a model, a lot of memory is needed to store all 
possible configurations. 

A number of approaches use Maude to specify the operational semantics of DSLs lITSlfTTll . Given the 
operational semantics of a DSL in Maude, other techniques can be applied to verify properties of DSL 
models. Both an LTL model checker [9] and a /x -calculus model checker flT] are available for rewrite 
systems specified in Maude. Although it is clear that model checking techniques can be implemented 
in Maude and applied to specifications of the semantics of DSLs, not all techniques applicable to LTSs 
which we aim to exploit, such as reduction and visualization, have been implemented in Maude. It might 
be the case, therefore, that a given technique must first be implemented in Maude before it can be used 
in combination with a specification of the semantics of a DSL. With our approach, we can connect to 
various tools and apply existing techniques only by adapting the representation of LTSs, if needed. 

6 Conclusions and Future Work 

Defining the semantics of SLCO by implementing a transformation that transforms SLCD models to LTSs 
has a number of advantages. Existing tools for verification and visualization can be reused, because 
LTSs are a common input representation used by a number of tools. The biggest advantages of using 
the ASF-i-SDF Meta-Environment for this implementation are ATerms, used for representing terms, and 
the command-line tools that can be automatically generated. Using ATerms guarantees efficient use of 
memory and the command-line tools offer efficient execution of rewrite rules, without any additional 
effort during the implementation. Both execution speed and efficient use of memory are important in this 
case because the state spaces of models represented by LTSs are typically very large. 

As future work we want to define a formal semantics of SLCO using, for instance, structural oper- 
ational semantics. The prototype of the semantics of SLCD and its implementation as presented here, 
make a solid ground for this work, as we got better understanding of the semantics of this DSL and were 
able to investigate a number of design decisions. As SLCD has the notion of time delays, future work is 
also going to investigate possibilities to connect our SLCO environment to languages and tools for time 
analysis. We also consider to apply the approach taken in this paper to other DSLs. The approach lends 
itself well for the creation of state-space generators based on the operational semantics of a given DSL, 
and prototyping the semantics of languages with informal or incompletely defined operational semantics. 
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